1. Field of the Invention
The present invention relates to a method and device for managing requests in an architecture of the client-server type.
2. Brief Description of the Related Art
For several years the general public has had the possibility of exchanging digital data through the Internet. More than a fashionable phenomenon, the Internet has become an unprecedented tool for sending an electronic message and/or obtaining information on almost any subject, and this almost in real time. The first sites, commonly referred to as Web sites, made it possible to download an application (or a page to the HTML format), and to “play” it (or to display it using a browser).
Many changes have been made both with regard to the formats of the files transferred and to the transfer protocols. With regard more specifically to the HTML file format, Web pages have become interactive, thus enabling the user to personalize the display of these pages and to send requests to the server storing the site being visited. In addition, these pages have become more attractive since this format has made it possible to encapsulate animations over time of multimedia objects.
Nevertheless, the size of the files transferred, that is to say the files which contain an application or an HTML page, must be minimal since the bandwidth of the Internet is always limited to a few kilobytes. So that the downloading time is not too great, the HTML format has been designed to make it possible to organize the data to be transferred in a hierarchic manner. Thus, by organizing these data hierarchically according to their order of use by the browser, it is possible to display an HTML page or to play an animation without waiting until all the file is downloaded. This property enables a user to browse on a site more easily.
For animations of multimedia objects, a file format (SWF) has been defined which makes it possible to describe animations over time of multimedia data using vectorial data. Thus the size of the HTML files remains within acceptable proportions. In addition, this format makes it possible to play the animation without waiting until all the file is downloaded. For these two reasons, this format is widely used for including animations of multimedia objects in an HTML page, and sites are beginning to appear designed exclusively with “Flash” data (the name commonly used to designate animations resulting from an SWF file).
As soon as a user requests the downloading of multimedia data from a server, the latter sends to the user a file which comprises so-called minimal data. From these data, the browser constructs an HTML page and displays it on a screen. Where this page contains a Flash animation, the data dedicated to this animation are interpreted by a Flash “decoder” integrated in the browser.
The data file can also comprise a set of commands which make it possible to recover additional multimedia data, once the file is downloaded. In addition, in the majority of applications, the minimal data enable the user to interact with the server in order to be able to recover additional information. This is what will be referred to hereinafter as “requests”.
As will be seen later, the present invention can be applied to any system for receiving multimedia data which includes requests of different origins.
In general terms, the requests are of different natures. They can be predictable, where they are included in the file downloaded initially and the data recovered, through these requests, are necessary to the correct running of an application (or of an animation). This set of requests is predefined by the designer of the application or of the animation. Others are unpredictable, such as the requests sent by the user. Finally, a last class of request makes it possible to anticipate the pre-fetching of multimedia data. This is because, as soon as a user has downloaded a file, it is possible to anticipate the future requests of this user and to pre-fetch data, so as to respond to these future requirements without delay. These requests are generally not predictable, since they change according to the actual requests of a user and the running of the application (or of the animation).
The majority of multimedia data transmission systems are not confronted with the problem of managing requests of different natures since the format of the data encapsulated in the file does not provide for the possibility of defining requests of different natures. Only the requests emanating from the user are managed, and sometimes those related to the application. Nevertheless, these systems do not manage several classes of requests at the same time.
The document U.S. Pat. No. 6,442,658 discloses a mechanism which manages a set of requests so that a Flash animation can be run correctly.
The SWF file used for defining a Flash animation is broken down into segments of data independent from one another. For example, a first segment comprises video data and a second segment image data. When the client machine receives the first segment, the Flash “decoder” must check that the resources necessary for playing the video, that is to say the memory available and the video data decoder, in cases where the data of the segment are coded, are available on the client machine. If the decoder is present on the client machine, the segment is played. In the contrary case, the Flash “decoder” extracts the location of this resource from the SWF file—usually an Internet link on a server—and sends the request to this server. Once the response has been received, the video decoder is installed on the client machine and the segment is played.
Thus, if several segments must be played, the most commonplace solution is to check whether all the resources necessary for playing the segments of an SWF file are available on the client machine. In a case where some of them are not, it is necessary to send requests to the various servers through information extracted from the SWF file.
Nevertheless, this solution cannot be envisaged since it would require too much storage memory and excessively long downloading times before being able to play the first segment. The document U.S. Pat. No. 6,442,658 proposes to resolve this problem by including a mechanism for pre-fetching these resources. This is because, when a segment is in the process of being played, this process downloads the data and the resources of the segment which will be played just afterwards. Once played, the data and resources are eliminated from the storage memory, thus avoiding an overloading of this memory.
The problem resolved by this document therefore consists of defining the segment which will be played at the end of the execution of the current segment. For this purpose, a priority is associated with each segment. This priority is the combination of the time necessary for the recovery of the data and resources and the probability that the segment is played just after the current segment.
The mechanism described in this document manages only one class of pre-fetching requests. In addition, the set of requests considered in this document is static, that is to say no new pre-fetching request is generated.